Formal Aspects of Grid Brokering* 



Attila Kertesz 

MTA SZTAKI 
1518 Budapest, P.O. Box 63, Hungary 



Zsolt Nemeth 

MTA SZTAKI 
1518 Budapest, P.O. Box 63, Hungary 



attila. kerteszOsztaki .hu 



zsnemethOsztaki . hu 



Coordination in distributed environments, like Grids, involves selecting the most appropriate ser- 
vices, resources or compositions to carry out the planned activities. Such functionalities appear at 
various levels of the infrastructure and in various means forming a blurry domain, where it is hard to 
see how the participating components are related and what their relevant properties are. In this paper 
we focus on a subset of these problems: resource brokering in Grid middleware. This paper aims 
at establishing a semantical model for brokering and related activities by defining brokering agents 
at three levels of the Grid middleware for resource, host and broker selection. The main contribu- 
tion of this paper is the definition and decomposition of different brokering components in Grids by 
providing a formal model using Abstract State Machines. 

1 Introduction 

Grid Computing has emerged from the area of Parallel and Distributed Computing more than a decade 
ago lfl4l . Since then numerous Grid projects have succeeded and Grids started to flourish. Recently 
several service Grid middleware solutions are used around the world |6j |7j [HI, and a wide variety of 
resource management tools - which are important components of grid computing infrastructure - are 
available and under development lfT31 . Resource management in Grids has many aspects and involves 
different approaches and means. Among those we have investigated brokering and established a Grid 
resource brokering taxonomy lfl2l to determine what properties brokers posses and what functionalities 
are desired for certain tasks. This survey shows that the currently available Grid resource management 
tools are built on different middleware components supporting different properties and named with a 
bunch of acronyms - even the ones having similar purposes. This plethora of approaches formed the 
domain of Grid resource management into a grey box with blurry boundaries where neither the users nor 
the researchers can clearly see how these tools are related and what their relevant properties are. Until the 
definitions and interrelations are clarified, further development and interoperability cannot be facilitated. 
Therefore, in an earlier work we aimed at an informal definition as Grid resource management anatomy 
in |[T3l . Present work can be considered as a continuation, investigating how the area of Grid resource 
management can be formalized and what essential layers, functionalities can be separated based on the 
formal model. 

A former work this paper is built on presents a formal definition for Grid Computing 1 16 ]. That time 
there had been several definitions for Grid Computing without the ability of making a clear distinction 
between Grids and other distributed systems. The paper concluded that Grids cannot be defined purely 
by their properties rather, their runtime semantics make the real difference. Based on the analysis, a 
formal definition was given for Grid Computing revealing its essential and characteristic functionalities. 
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The aim and methodology of this paper is similar: establishing a formal, semantic model for Grid re- 
source management using Abstract State Machine. We extend the formal model for Grids defined in 
lfl6l by classifying brokering components into three categories and defining three agents for resource 
management at different levels of Grid systems. 

We are not aware of any other works that investigate formal models specifically for grid resource 
manager components. Bratosin et al. proposed a reference model for Grid architectures based on colored 
Petri nets in H. Though they provide a definition for job scheduling, they do not detail brokering steps 
and mechanisms at different levels. Altenhofen et al. investigated Service Oriented Architectures in HI, 
more specifically service discovery, mediation and composition. These components have some similar 
functionalities but this work is more focused on a unified, higher level service framework, and do not 
explore resource manager components. Borger et al. proposed an ASM model for workflows in Q. 
The work presents workflow interpretations and transitions, which are related to our model, but they 
stay at the application level and do not deal with brokering at job level whereas our model targets the 
middleware below the application level. 

In the following section we give a brief introduction of the formal Abstract State Machine method, 
and in Section [3] we summarize the formal model for Grid Computing introduced in [16] and describe 
our modified model. In Section|4]we present and describe the extensions for Grid brokering components 
and in Section [5] we refine agents responsible for broker and host selection. Finally Section [6] concludes 
the paper. 



2 Abstract State Machines 

ASM represents a mathematically well founded framework for system design and analysis [2j. It is able 
not just to model a working mechanism precisely but also to reveal the highly abstract nature of a system, 
i.e. to grasp the semantics 00. Furthermore - unlike many other state based modeling methods -, it can 
easily be tailored to the required level of abstraction. Logicians structures applied in ASMs offer an 
expressive, flexible and complete way of state description. The basic sets and the functions interpreted 
on them can be freely chosen to the required level of complexity and precision Q. 

In ASM, a signature (or vocabulary) is a finite set of function names, each of fixed arity. Further- 
more, it also contains the symbols true, false, undef, = and the usual Boolean operators. A state A of 
signature T is a nonempty set X together with interpretations of function names in T on X. X is called the 
superuniverse of A. An r-ary function name is interpreted as a function from X r to X, a basic function 
of A. A 0-ary function name is interpreted as an element of X |9|. A location of A (can be seen like the 
address of a memory cell) is a pair / = (/, a), where / is a function name of arity r in vocabulary T and 
a is an r-tuple of elements of X. The element f{a) is the content of location /. An update is a pair a = (I, 
b), where I is a location and b is an element of X. Firing a at state A means putting b into the location / 
while other locations remain intact. The resulting state is the sequel of A. It means that the interpretation 
of a function / at argument a has been modified resulting in a new state. ASMs are defined as a set of 
rules. An update rule f(a) := b causes an update ((/, a), b), i.e. hence the interpretation of function / 
on argument a will result b. It must be emphasized that both a and b are evaluated in A. 

The nullary Self function allows an agent to identify itself among other agents. It is interpreted 
differently by different agents (that is why it is not a member of the vocabulary.) An agent a interprets 
Self as a while an other agent cannot interpret it as a. The Self function cannot be the subject of updates. 
A conditional rule R is of form 
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ifc 

then Ri 
else 

R 2 
endif 

To fire R the guard c must be examined first and whenever it is true R\ otherwise, R2 must be fired. A 
block of rules is a rule and can be fired simultaneously if they are mutually consistent. Some applications 
may require additional space during their run therefore, the reserve of a state is the (infinite) source where 
new elements can be imported from by the following construct 

extend U by vi, . . . , v„ with 
R 

endextend 

meaning that new elements are imported from the reserve and they are assigned to universe U and 
then rule R is fired [9]. 

The basic sequential ASM model can be extended in various ways like non-deterministic sequen- 
tial models with the choice construct, first-order guard expressions, one-agent parallel and multi-agent 
distributed models. A distributed ASM [2] consists of a finite set of single-agent programs IT n called 
modules, a signature T, which includes each Fun(Yl n )-{Self}, i.e. it contains all the function names of 
each module but not the nullary Self function, and a collection of initial states. 

As it can be seen, ASM states are represented as (modified) logicians structures, i.e. basic sets 
(universes) with functions interpreted on them. Structures are modified in ASM to enable state transitions 
for modeling dynamic systems. Applying a step of ASM M to state (structure) A will produce another 
state A' on the same set of function names. If the function names and arities are fixed, the only way of 
transforming a structure is to change the value of some functions for some arguments. Therefore, the 
most general structure transformation (ASM rule) is a guarded destructive assignment to functions at 
given arguments (2). 

Refinement is defined as a procedure where abstract and more concrete ASMs are related accord- 
ing to the hierarchical system design. At higher levels of abstraction implementation details have less 
importance whereas they become dominant as the level of abstraction is lowered giving rise to practical 
issues. Its goal is to find a controlled transition among design levels. 

3 ASM for Grid Computing 

Before we define our model, we summarize the ASM for Grids defined in lfl6l . Figured] (a) shows the 
important elements of this model. The ASM universes of the model are depicted on the left of the figures, 
and on the right a graphical representation of the connections of some elements of these universes and the 
most relevant functions governing process execution are shown. In this model user applications consist 
of one or more processes, while Grids consist of several nodes having one or more resources. During the 
execution of the user application first an agent maps the actual process of the application to a resource 
in the Grid, then the process is installed on the node of the resource as a task, which starts to use the 
resource. When all the processes of the application finished using their resources, the application is 
finished. 
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We extend this formal model by introducing Grid brokering at different levels. The basic model of 
grid systems introduced in [16] is presented in a slightly modified form here. The modification is indi- 
cated by introducing more practical issues related to realization; aligning the model to the terminology 
and naming conventions of grid brokering; and finally by experiences in Grid Computing since the paper 
was published. These modifications do not invalidate or alter the content and conclusion of the initial 
model just add more relevant details. The modifications are shown in Figure [T] (b). In the following 
subsections we define the basic elements of our proposed extended formal model based on ASM: the 
universes, the signature and the rules. 



3.1 Universes and signature 

To define our formal framework, first we need to examine real service Grid systems. Certain objects 
of the physical reality are modeled as elements of universes and relationships between real objects are 
represented as functions and relations. In Grid systems users (universe USER) define their applications 
in the form of jobs (universe JOB), which is the most typical computing paradigm for Grids hence, we 
restrict our model to this case. A job consists of one or more processes (universe PROCESS). The 
installed instances of processes are called as tasks (universe TASK), which can be run on different hosts 
(universe HOST). Hosts are the building blocks of Grid systems, and typically a job is sent to a host 
for execution. A host may have several nodes (e.g. when a host is a cluster), and nodes have certain 
resources that processes require to run. Since nodes are usually invisible (and unmanageable) for higher 
level tools, therefore we neglect them in our model. In this way one or more physical resources (universe 
PRE SOU RCE) belong to a host, which also determines the physical location (universe LOCATION) of 
the resources. The processes of jobs require some of these resources to run. Users should select a host 
according to these resource requirements, which we call as abstract resources (universe ARE SOU RCE). 
Information on the physical resources of the hosts can be gathered by querying the information system 
of a Grid. 

Once a job is submitted to a host, it is mapped to physical resources during execution. While a 
resource is busy, the mapped process is in waiting state. When the resource becomes free, the process 
starts using it and enters running state. Process termination implies a done state in case of successful 
run, and a. failed state in case of an error. In general, Grid authorization allows users to log in to some 
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hosts and validates user privileges to use some resources of some hosts [5]. The requested (abstract) and 
the physical resources have certain attributes (universe ATTR). Compatibility between an abstract and 
a physical resource means the physical resource can satisfy the process requirement. According to this 
informal description, the following functions are used in the model: 

job: PROCESS -» JOB 

user, globaluser, localuser: JOB — > U SER 

submitted: JOB x HOST -> {true, false} 

procRequest: PROCESS x ARE SOURCE -> {true, false} 

uses: PROCESS x PRE SOURCE -> {true, false} 

mapped: PROCESS -> LOCATION 

belongsTo: PRE SOURCE x ffOST -> {true, false} 

installed: TASK x LOCATION -> {true, false} 

attr : {ARE SOURCE , PRE SOURCE } — > ATTR 

location: PRESOURCE -» LOCATION 

handler: PRESOURCE -» PROCESS 

type: PRESOURCE ^ ATTR 

compatible: ATTR xATTR — > {true, false} 

canLogin: USER x HOST —> {true, false} 

canUse: t/SEfl x PRESOURCE -» {true, false} 

jobState: JOB^ {submitted , running, waiting, done , failed} 

procState: PROCESS — > {running, waiting} 

event: TASK — > {start, abort, terminate} 

mappedHost: 705 -> //OSr 

mappedResource: PROCESS x ARESOURCE -> PRESOURCE 



3.2 Initial state 

We assume that it processes belong to a job of a user. The job and its processes have some requirements, 
and no process and job is mapped to any resource or host. Therefore the states of the jobs and processes 
are undefined. In the following we define the initial state of our model: 

3pi ,/?2 ; ■ ■■ ,Pk £ PROCESS : job(pj) ^ undef, I <i<k 
Vpi, 1 < i < £ : user(/7 ; ) =«£ USER 

Vpi, 1 < i < it : 3ar £ ARESOURCE : procRequest(/? ( - , ar) = frwe 

1 < ? < Jt : 3/>r G PRESOURCE : uses(p t ,pr) = false 
Vj : mappedHost(j) = undef 
Vp;, 1 < i < ife : task(/?,) = undef 
Vpi, 1 < i < £ : mapped(/? ! ) = undef 
V/ : jobState(7) = undef 
Vpi, 1 < i < A; : procState(/?,) = undef 
Vw G , 3pr u pr2, . . . ,pr m G PRESOURCE : 

canUse(w, /?r,) = frwe, 1 <i<m 

After we have defined the universes and the signature, in the following we give the rules of our model 
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that constitute a module, i.e. a program that is executed by each agent in the model. The model presented 
here is a distributed multi-agent ASM where agents are jobs, i.e. elements from the JOB universe. The 
working behavior of the brokering model is depicted from the perspective of the jobs hence, the self 
function is represented as j and means the identity of a job, i.e. it can identify itself among other agents. 
It is interpreted differently by different agents. 

3.3 Rule 1: Resource selection 

According to Figure [T](b), when the job is sent to a host, the required resources need to be selected that 
are used by the processes of the job. During job execution, a task of each process is installed to the loca- 
tion of the required and selected resource. The precondition of resource selection is that the process of 
the job should be able to use the mapped resource. In case of the process can directly access the physical 
resource (r^) the execution (resource usage) is automatically started, otherwise a local handler process 
should provide the execution platform (i.e. the additional software or service). If this handler process 
does not exist, it should be started before execution. The agent responsible for resource mapping needs 
to ensure that the chosen resource fulfills the abstract resource requirement of the process. Here is the 
formal definition: 

let h = mappedHost(j') 
letjobO) = j 

let pr = mappedResource(p, ar) 
if {Bare ARE SOURCE): 

procRequest(/?, ar) = true & pr ^ undef & canUse(user(/?), pr) = true 
then if type(pr) = rj 

then mapped(/j) := location(/?r) 
installed(task(/?), location(/?r)) :=true 
else if ( -Bp' G PROCESS ): handler(^r) = p' 
extend PROCESS by p' 
with mapped(//) := location(/?r) 
installed(task(//), location(/?r)) := true 
handler(/?r) := p' 
do forall ar £ ARESOURCE 

procRequest(//, ar) := false 
enddo 
endextend 
endif 

procRequest(p, ar) := false 
uses(p, pr) := true 
endif 



1 lresource_mapping 

if ( 3ar € ARESOURCE, 3p G PROCESS, 3h G HOST ): 
]ob(p) = j & mappedResource(/7, ar) = undef & 
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procRequest(p, ar) = true & h = mappedHost(j) 
then choose pr in PRE SOURCE 

satisfying compatible(attr(ar), atti(pr)) & belongsTo(/?r, h) = true 
mappedresource(/?, ar) := pr 
endchoose 
endif 

Here, we note that though generally a job runs on a host (if it is a parallel job of communicating 
processes, it runs on a number of nodes of this host parallelly), some middleware tools may enable co- 
allocation of parallel processes on nodes of different hosts. We do not deal with this situation, since it is 
rarely used and supported, but further refinement of our model could represent such cases. 

Before job execution it is necessary to authenticate users. In Service Grids users are authenticated 
by proxies of grid certificates Q. A local process is responsible for validating these proxies by mapping 
global users to local ones having the same privileges. The related formalism of user mapping is similar 
to the one presented in lfl6l . 

3.4 Rule 2: State transition 

In this subsection we define, how job states are evolving during execution: 

if ( 3h G HOST ): submitted(j, h) = true 

then jobState(j) := submitted 
endif 

if ( 3p G PROCESS ): jobQ?) = j & mapped(p) / undef 

then procState(p) := waiting 

jobState(j) := waiting 
endif 

if ( 3pr 6 PRESOURCE, 3p G PROCESS ): )ob{p) = j& uses(p, pr) = true 

then procState(/j) := running 

jobState(j) := running 
endif 

if ( 3p e PROCESS, 3t G TASK, 3pr G PRESOURCE, 3h G HOST ): 
uses(/?, pr) = true & belongsTo{pr,h) = true 
& installed(f, h) = true & event(£) = abort 
then jobState(j) := failed 
PROCESS(p) := false 
endif 

Though in general, process spawning could cause additional resource requests for job execution in 
a host, we do not detail this in our model, and keep it as abstract as possible, since at the level of grid 
brokering process communications and spawning are invisible. In order to handle these situations, we 
assume that resource requests of spawned processes are known a priori. State transitions related to job 
termination are formalized in Rule 3. 
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3.5 Rule 3: Termination 

Job execution is terminated under the following conditions: 

if (3pe PROCESS): 
job(p) = j & procState(p) = running & event(task(p)) = terminate 
then PROCESS(p) := false 
endif 

if ( . . . ,p m G PROCESS ): job(/? ; ) = j & jobState(j) = failed, l<i<m 

then PROCESS(pd := /a/se 
endif 

if ( -.3/? G PROCESS ): job(/>) = ; & jobState(j) = running 

then jobState(7) := done 
endif 



4 ASM for Grid Brokering 

This section focuses on middleware components responsible for brokering in Grids. In our ASM model 
these components are represented by agents (also called as modules). First we give an informal overview 
of these components and their roles in Grids and demonstrate their usage in a typical Grid application 
execution scenario. In the following subsections we show how these components can appear as agents 
in the formal model described above. Furthermore we emphasize how these brokering components con- 
tribute to Grid Interoperability, i.e. how they support transparent job submissions to different, separated 
Grids. 

At the lowest level of Grid resource management we can find local resource managers (also called 
as schedulers or cluster managers, e.g. PBS 11171 ) that were taken from high-performance and distributed 
computing, and now generally used in Grid Systems. Their goal is to schedule and manage single and 
parallel programs and their processes locally. This local management is formalized in Rule 1 of or model. 
In this case interoperability is not supported at all. Without additional brokering components users need 
to choose from the available hosts manually relying on mostly static information. 

One level above, a grid Resource Management System (RMS), also called as a Grid resource broker, 
is needed to automate host selection. It can be an internal middleware service, or an external tool that uses 
other middleware components or services. (Note that the word "resource" is used differently in our model 
as in the expression "resource broker". In our model we call the computing and storage elements of Grids 
as "hosts", and "resources" are the physical components of the hosts, e.g. processor and memory.) While 
local managers usually schedule user programs in a grid host (e.g. in a cluster) among free processors, 
the Grid broker schedules jobs at the level of Grid middleware by selecting a host that best matches 
the requirements of these jobs. (Thus, the selected host can also be a cluster with a local manager.) 
Therefore, a broker is also called as a meta-scheduler - more information on broker naming conventions 
and their connections can be found in lfl3l . Some of them support different middleware solutions, job 
types, agreements or various quality of service (QoS) attributes. Furthermore different brokers may be 
connected to different hosts and Grids. A taxonomy in lfT2l introduces these properties and shows the 
differences among the currently used brokers, their properties, organization and connections and among 
their level of interoperability. In our future work we also plan to represent interoperability as a metric in 
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our model in order to categorize and differentiate various brokering components. 

With the help of grid brokers, host selection is automated, but users are still bound to separate grid 
islands (i.e. grid systems that are complete systems on their own but closed to any form of interoperability 
between each other, either by technology, compatibility, administrative or other restrictions) managed by 
their own brokers. Nevertheless users have the ability to select manually, which broker and Grid they 
would like to use (even static information on broker properties are available in form of manuals or 
taxonomies e.g. in [12]). In order to achieve the highest level of interoperability broker selection should 
also be automated. Therefore at the highest level we can find meta-brokering ifTTI . which is a novel 
approach that introduces another layer above current grid brokers in order to facilitate inter-grid load 
balancing and interoperable brokering. The Grid Meta-broker sits on top of Grid brokers and uses meta- 
data to decide which broker should be selected for a user's job. To demonstrate the interoperation of 
these brokering components, we describe a typical Grid usage scenario for a job execution that requires 
the following steps: 

1. The user defines its application as jobs, also stating the requirements of its execution. 

2. The user requirements of the job is examined by the meta-broker, and mapped to the properties of 
the available brokers. A proper broker, that is able to submit the job, is selected for submission. 

3. The selected broker examines the resource requirements of the job and matches them to the physi- 
cal resources of the available hosts. A host having all the required resources is selected for execu- 
tion. 

4. The agent on the selected host (the local resource manager) maps the resource requirements of the 
job to the available physical resources during execution. 

In the following subsections we define two more rules to model the informal description and discus- 
sion above. We need additional universes and functions to incorporate brokering into our model. 

4.1 An additional rule for Grid Brokering 

Brokers (universe BROKER) are responsible for host selection, therefore hosts are managed by brokers, 
which can have different properties (universe PRORERTY) that users may require for job execution. 
A user should select a broker for its job according to these requirements (universe REQUIREMENT). 
Furthermore we place universe ARE SOURCE as a subset of universe REQUIREMENT, since the ele- 
ments of both sets represent user requirements, and universe PRESOURCE can be a subset of universe 
PRORERTY, because physical resources can be regarded as host properties. The following functions are 
added to the model: 

request: JOB x REQUIREMENT {true, false} 
submitted: JOB x {HOST, BROKER} -> {true, false} 
manages: HOST x BROKER -> {true, false} 
have: BROKER x PRORERTY -> {true, false} 
attr: {REQUIREMENT, PRORERTY} ^ATTR 

We extend the initial state by: 



Mj : 3r G REQUIREMENT : request(j,r) = true 



A. Kertesz & Zs. Nemeth 



27 



Elements and Functions 



JOB 
PROCESS 
ARESOURCE 



BROKER 



HOST 
PRESOURCE 



j 




Pi 

@ © 




Pn 

©..© 




Universes 
JOB 

REQUIREMENT 
METABROKER 



BROKER 
PROPERTY 



Elements and Functions 



<ss> <s> 



HOST 




(a) 



(b) 



Figure 2: (a) Grid brokering and (b) Meta-brokering in the ASM model. 
We extend Rule 2 with the following state changes: 

if ( 3b G BROKER ): submitted(j, b) = true 

then jobState(j) := submitted 
endif 

if ( 3h G HOST ): submitted( j, h) = true 

then jobState(j) := waiting 
endif 

Once a broker is selected by the user, it should find an execution host. The precondition of this host 
selection process is that the user of the job should be able to use the required resources of the selected 
host. The broker agent responsible for host mapping needs to ensure that the chosen host has all the re- 
sources requested by the processes of the job. This additional component responsible for Grid brokering 
is highlighted in Figure |2](a). In the following we state the formal definition: 

Rule 4: Host selection 
h = mappedHost(j) 

if (3an,...,ar m G ARESOURCE ,3pr h ... ,pr m G PRESOURCE ): 
request(j, ar,) = true & undef 

& canUse(user(j), pr^) = true, belongsTo(j?r£, h) = true, 1 <i,k <m 
then submitted(j, h) := true 
endif 



FIhost_mapping 

if ( 3j G JOB, 3ar x ar m G ARESOURCE, 3pr u . . . ,pr m G PRESOURCE ): 
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mappedHost(j) = undef & request^', ar,) = true, 1 <i <m 
then choose h in HOST 

satisfying compatible(attr(ar i ), attr(pr,t)) 
where belongsTo(/?r,t , h) = true, 1 <i,k<m 
mappedhost(j) :=h 
endchoose 
endif 



4.2 Rule 5: Broker selection 

At the highest level of Grid resource management a broker needs to be selected automatically for a user 
job. An important precondition of the selection process is that such a broker needs to be selected that 
manages hosts with resources that the user of the job can use. Furthermore the agent responsible for 
broker selection, the meta-broker (universe METABROKER) needs to ensure that the chosen broker has 
all the properties required by the user's job. Therefore users need to characterize their job requirements 
in a certain job description language, which should include both the required broker properties and ab- 
stract resources of the processes of the job. This additional Grid middleware component is highlighted 
in Figure |2](b). The following function is added to the model: 

mappedBroker: JOB -> BROKER 

We extend the initial state by: 

Vj : mappedBroker(7) = undef 

The formal definition of the meta-broker agent is as follows: 
let b = mappedBroker(j) 

if ( 3r £ REQUIREMENT, 3pr £ PRESOURCE, 3h £ HOST ): 

request^', r) = true & b ^ undef & canUse(user(j), pr) = true, 

belongsTo(/?r, h) = true, manages(/z, b) = true 
then submitted(j, b) := true 
endif 

nbroker_mapping 

if ( 3n , ■ ■ ■ , r m £ REQUIREMENT, 3p h ... ,p m £ PROPERTY, 3j £ JOB, 
3b £ BROKER ): 

mappedBroker(7) = undef & V/ : request^', r ; ) = true 
& V/ : have(Z?, p{) = true, 1 < / <m 
then choose b in BROKER 

satisfying compatible(attr(r, ), attr(/?0), 1 < i < m 

endif 
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Finally we should state that jobs can be interconnected in order to form a complex Grid application 
called as workflows. The execution of workflows require a coordinating tool called workflow enactor that 
schedules the interdependent jobs for executions. We refrain from formalizing workflow management 
and incorporate it into our model, since our central entities are jobs, and therefore assume that grid 
applications are submitted into the system in the form of jobs. 

As a summary, we have shown that grid brokering takes place at three levels, and the following 
operations need to be performed: broker mapping, host mapping and resource mapping. In the following 
section we show, how practical examples of these components can be described by our formal ASM 
model with the help of ASM refinement. These tools are the Grid Meta-Broker |[TT1l and GTbroker iflQl . 

5 Refinement of Broker Components 

This section contains illustrative examples, how the generic brokering model can be refined into models 
that represent realised implementations of the brokering principles. One can see in these examples how 
certain functions, kept abstract in Rule 4 and 5 presented earlier, are transformed to reveal implementa- 
tion details. More information on the realization and practical utilization of these tools can be read in 

ina. 

5.1 Refinement of broker mapping (matchmaking of the Grid Meta-Broker) 
IT 

broker_mapping 

if ( 3r h . . . ,r m G REQUIREMENT, 3p h ...,p n E PROPERTY, 
3 j G JOB, 3bi , . . . , b, G BROKER, 3vi , . . . , v, G REAL ): 

mappedbroker(j) = undef & V? : request(j, r t ) = true, 1 <t<m, 
& Vz : ha.ve(bk, pi) = true, 1 <i < n, 1 <k <l 
then doforall/t (1 <k<l) 
V/t := getBrokerPerf^) 

if ( — i3f , i ): attr(r ; ) = attr(p ; ) & have(^, /?,) = true, 1 <t <m,l <i <n 
then Vk '■= 
enddo 

choose v max m{v\,...,vi ) 

satisfying v max > v^, 1 < k,max < I 
mappedbroker(j) := b max 
endchoose 
endif 

In addition to the broker mapping defined in Rule 1, this refinement details how the compatible func- 
tion is implemented. In case of the Grid Meta-broker, the attributes of the broker properties are certain 
keywords. The users have to use the same keywords in their requirement specifications, therefore com- 
patibility means exact string matching. The refined agent also uses an additional function getBrokerPerf: 
BROKER — > REAL, which returns a real number denoting the dynamic performance of the appropriate 
broker. The higher this value is the better the broker performs. 
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5.2 Refinement of host mapping (matchmaking of GTbroker) 

TT' 

host_mapping 

if ( 3j € JOB, Ban ,...,ar n € ARE SOURCE, Bpolicy € REQUIREMENT, 
3pr u ...,pr m ePRESOURCE,3h h ...,h t eHOST,3r u ...,r t eREAL): 
mappedhost(j') = undef & request^', policy) = true, 
request(j, art) = true, 1 < i < n < m 
then doforall£(l <k<t) 
rt := countRank(/?o//cy, hu) 
if ( -i3Z, i ): attr(ar,) < attr(pr ( ) 
& belongsTo(/?r/ , hk) = true, 1 < i < n, 1 < / < m 
then rjt := 
enddo 

choose r max in ( r x , . . . , r, ) 

satisfying r mffiC > r fc , 1 < k,max < t 
mappedhost(j) := h mwc 
endchoose 
endif 

In addition to the host mapping defined in Rule 2, this refinement also reveals the meaning of the 
compatible function. In case of GTbroker, the attributes of resource requirements denote the amount of 
resource capacity (e.g. memory size or processor speed) needed by the processes of the job for execution. 
This means, if the available physical resource has equal or greater capacity than requested, the process 
can run. The host selection method can be influenced by users using the special policy requirement. 
The value of its attribute tells the additional countRank: REQUIREMENT x HOST -> REAL function 
how to compute the rank for the available hosts (e.g. higher priority can be given to hosts with faster 
processors). Finally, the host with the highest rank is selected for execution. 

6 Conclusions 

In this paper we have investigated the brokering components of the Grid middleware and defined a 
three-layered formal model using Abstract State Machines. In this model three agents are responsible 
for resource management by performing three selection processes: broker mapping, host mapping and 
resource mapping. We have also proposed two refined definitions for broker and host selection, which 
are implemented by the Grid Meta-broker and GTbroker. Our future work aims at introducing inter- 
operability metrics for categorizing brokering components and using the ASM model for verifying our 
categorization. 
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